Large software applications are often composed of unmanageably large amounts of executable code. In order to facilitate creation and management of large software systems, then, the systems are often composed of many different components, called business objects. Business objects are software components that encompass user interfaces, data, business rules, communication components and any other code that may relate to their function.
In order to simplify design of these large systems, business objects are often defined as collections of logically related functions and data. A large application designed to facilitate a typical mail order business may have many different business objects. An ordering business object may be used to handle incoming orders or changes to existing orders. A shipping business object may be implemented to handle all shipping related tasks, such as arranging for deliveries or determining shipping times and costs. Business objects may handle some tasks independently while communicating with other business objects to complete other tasks. Business objects may also be grouped into larger components, called deployment units (DUs), that represent related groupings of business objects. As billing and ordering are often tightly related, they may be placed in a single DU. Customer databases and employee payroll, however, are not related at all and thus would usually be placed in separate DUs. DUs may then be deployed to systems as independent units, sharing a single computing device or spanning many such devices connected over a variety of networks.
This design model suffers from several problems however. First, storing many different components all in one business object may make its operation slower. Whenever one part of the business object is acting, the others may be suspended until that action is complete. Thus, if one business object communicates with another business object in order to perform a coordinated action, both business objects could be locked until that operation is complete. Users would be unable to use the objects, nor would other business objects be able to communicate with them, until the operations were completed.
When integrating business objects together, a user encounters another severe deficiency of the present system. A business object cannot be designed to coordinate with every imaginable other business object, and thus some changes will have to be made to one or both of the newly integrated business objects in order to coordinate their operations. As discussed above, this leads to a shutdown and upgrade of at least one of the business objects, as well as a review of the entire inner working of the business objects in order to learn which components within them must be changed.
Accordingly, there is a need in the art for a system that uses separate objects, called process agents, to integrate business objects and a data store to maintain persistency in the application system.